Update plugin-getter version matching check #12953
Conversation
|
I find that writing directly into the plugin directory and removing if the binary invalid is a bit finicky when it comes to the test. I’m going to update this to include your temporary file writing changes and then have it do a rename instead of opening and copying a new file. |
nywilken
force-pushed
the
nywilken/harden_remote_plugins_consolidation
branch
2 times, most recently
from
50ed7cd to
5effa77
Compare
nywilken
force-pushed
the
harden_remote_plugin_installs
branch
from
1a37f84 to
709fdcd
Compare
nywilken
force-pushed
the
nywilken/harden_remote_plugins_consolidation
branch
2 times, most recently
from
b6e8a4d to
269920b
Compare
| @@ -976,6 +974,12 @@ func CheckVersion(filename string, identifier string, version *goversion.Version | |||
| err := fmt.Errorf("binary reported version (%q) is different from the expected %q, skipping", desc.Version, version.String()) | |||
| return &ContinuableInstallError{Err: err} | |||
| } | |||
| if version.Prerelease() != "" { | |||
There was a problem hiding this comment.
In cases where a plugin is tagged and released as a prerelease but the describe version is actually a final version (e.g github.com/hashicorp/hashicup@v1.2.0-dev) Packer should prevent the installation because of a mismatch version that will not load properly.
There was a problem hiding this comment.
Plugin "github.com/hashicorp/hashicups" release v1.0.2-dev binary reports version "1.0.2-dev". This is likely an upstream issue.
Yeah I get this on my latest harden branch, so my original hunch that we got the candidates through a Constraint is not right it seems. IMHO, we should reject remotely installing non-final versions of a plugin, even before we even try to contact Github, so we should check the version requested, and only accept final versions for commands like plugins install or packer init.
nywilken
force-pushed
the
nywilken/harden_remote_plugins_consolidation
branch
from
ade8d2f to
f67da39
Compare
This change is an attempt to remove the need for additional temporary files, along with calls to stat the temp files, to reduce the number of files being created, opened, and closed. In addition to this change, the logic for falling back to a previous version if the highest matched version is a pre-release has been removed. Instead we will assume that any prior versions will exhibit the same issue and return immediately. A user can install the version manually if they will or they can modify their version constraint to a properly released version.
``` ~> packer init mondoo_req.pkr.hcl Failed getting the "github.com/mondoohq/cnspec" plugin: error: Remote installation of the plugin version 10.8.1-dev is unsupported. This is likely an upstream issue with the 10.8.1 release, which should be reported. If you require this specific version of the plugin, download the binary and install it manually. packer plugins install --path '<plugin_binary>' github.com/mondoohq/cnspec ```
nywilken
force-pushed
the
nywilken/harden_remote_plugins_consolidation
branch
from
f67da39 to
34cb984
Compare
* Only create plugin directories if there is potential plugin install
… a prerelease * Refactor InstallError string messages
nywilken
force-pushed
the
nywilken/harden_remote_plugins_consolidation
branch
from
34cb984 to
66ef512
Compare
lbajolet-hashicorp
merged commit e5434bf
into
harden_remote_plugin_installs
lbajolet-hashicorp
deleted the
nywilken/harden_remote_plugins_consolidation
branch
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
This change is an attempt to remove the need for additional temporary files, along with calls to stat the temp files, to reduce the number of files being created, opened, and closed. Instead of creating a temp file for the binary we download it into the expected directory if after validation we find that the file is invalid or has a mis-matched version the file is deleted.
In addition to this change, the logic for falling back to a previous version if the highest matched version is a pre-release has been removed. Instead we will assume that any prior versions will exhibit the same issue and return immediately. A user can install the version manually if they will or they can modify their version constraint to a properly released version.